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The RObust Header Compression (ROHC) Framework 
Abstract 


The Robust Header Compression (ROHC) protocol provides an efficient, 
flexible, and future-proof header compression concept. It is 
designed to operate efficiently and robustly over various link 
technologies with different characteristics. 


The ROHC framework, along with a set of compression profiles, was 
initially defined in RFC 3095. To improve and simplify the ROHC 
specifications, this document explicitly defines the ROHC framework 
and the profile for uncompressed separately. More specifically, the 
definition of the framework does not modify or update the definition 
of the framework specified by RFC 3095. 


This specification obsoletes RFC 4995. It fixes one interoperability 
issue that was erroneously introduced in RFC 4995, and adds some 
minor clarifications. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5795. 


Sandlund, et al. Standards Track [Page 1] 


RFC 5795 ROHC Framework March 2010 


Copyright Notice 


Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 


Table of Contents 


1. Introduction 4 
2. Terminology 5 
2.1. Acronyms Rodeo a aa a a a e ert a oe ea ee AA D 
2.2.  ROHC Terminology Se at n cb dg? a ca r ae et e aa a oa ey ee Ge og si^. O 
3. Background (Informative) ee : 8 
3.1. Header Compression Fundamentals be les gt se ue A) gh a ue. ue B 
3.2. A Short History of Header Compression .......... 9 
4. Overview of ROHC (Informative) . . . . . . . . . . . . . . . . 10 
4.1. General Prineorvrples «oh o e A ck cece A Ge lm de $9. 8s D S ALO 
4.2. Compression Efficiency, Robustness, and Transparency . . . 11 
4.3. Developing the ROHC Protocol... Sin tee i a css nM DA 
4.4. Operational Characteristics of the ROHC "Channel. Bao. cs, E. 
4.5. Compression and Master Sequence Number (MSN) . . . . . . . 14 
4.6. Static and Dynamic Parts of a Context . . . . . . . .. . 15 
5. The ROHC Framework (Normative) . . . . . . . . . . . . . . . . 15 
5.1. The ROHC Channel . . . . bn dS do qua. lecho Me oi arch 
5.1.1. Contexts and Context Identifiers Mew Se a Ber ee de. ae SLD 
5.1.2.  Per-Channel Parameters . . . Se uh iode See ke ta ut xe, EG 
5.1.3. Persistence of Decompressor Contexts MIETEN NY 


Sandlund, et al. Standards Track [Page 2] 


RFC 5795 ROHC Framework March 2010 
5.2.  ROHC Packets and Packet Types 17 
5.2.1. General Format of ROHC Packets 18 
5.2.1.1. Format of the Padding Octet 19 
5.2.1.2. Format of the Add-CID Octet 19 
5.2.1.3. General Format of Header S. bs uico Cete dus o 2 eie e > ua SEED. 
5.2.2. Initialization and Refresh (IR) Packet Types . . . . . 20 
5.2.2.1.  ROHC IR Header Format 20 
5.2.2.2.  ROHC IR-DYN Header Format Se Is 2l 
5.2.3.  ROHC Initial Decompressor Processing . . . . .. . . . 22 
5.2.4. ROHC Feedback 23 
5.2.4.1.  ROHC Feedback Format 24 
5.2.5. ROHC Segmentation Dcum 26 
5.2.5.1. Segmentation Usage Donsidesat tons s^ e EL de y es Let AO 
5.2.5.2. Segmentation Protocol 26 

5.3. General Encoding Methods B aoa Ae ek Ge A P eec ye 8 
5.3.1. Header Compression CRCs, Coverage, and Polynomials . . 28 
5.3.1.1. 8-bit CRC in IR and IR-DYN Headers . . . . . . . . 28 
5.3.1.2. 3-bit CRC in Compressed Headers 28 
5.3.1.3.  7-bit CRC in Compressed Headers 29 
5.3.1.4. 32-bit Segmentation CRC ey! en D Me. ah es hf AD) 

5322 Self-Describing Variable-Length Valdes $3. EOS 10) 
5.4.  ROHC UNCOMPRESSED -- No Compression (Profile 0x0000) | + + 30 
54.1 IR Packet modis dh Gates, T E S 31 
5.4.2 Normal Packet 32 
5.4.3. Context Tnitialization 32 
5.4.4. Decompressor Operation 33 
5.4.5. Feedback a S^ wow VAL rs 33 

6. Overview of a ROHC Profile (Informative) 33 
7. Acknowledgments 35 
8. IANA Considerations 35 
9. Security Considerations 36 
10. References a, = at eS 37 
10.1. Normative References 37 
10.2. Informative References 37 
Appendix A.  CRC Algorithm 39 


Sandlund, et al. Standards Track 


[Page 3] 


RFC 5795 ROHC Framework March 2010 


l« 


Introduction 


For many types of networks, reducing the deployment and operational 
costs by improving the usage of the bandwidth resources is of vital 
importance. Header compression over a link is possible because some 
of the information carried within the header of a packet becomes 
compressible between packets belonging to the same flow. 


For links where the overhead of the IP header(s) is problematic, the 
total size of the header may be significant. Applications 
transferring data carried within RTP [RFC3550] will then, in addition 
to link-layer framing, have an IPv4 [RFCO791] header (20 octets), a 
UDP [RFCO768] header (8 octets), and an RTP header (12 octets), for a 
total of 40 octets. With IPv6 [RFC2460], the IPv6 header is 40 
octets for a total of 60 octets. Applications transferring data 
using TCP [RFCO793] will have 20 octets for the transport header, for 
a total size of 40 octets for IPv4 and 60 octets for IPv6. 


The relative gain for specific flows (or applications) depends on the 
Size of the payload used in each packet. For applications such as 
Voice over IP, where the size of the payload containing coded speech 
can be as small as 15-20 octets, this gain will be quite significant. 
Similarly, relative gains for TCP flows carrying large payloads (such 
as file transfers) will be less than for flows carrying smaller 
payloads (such as application signaling, e.g., session initiation). 


As more and more wireless link technologies are being deployed to 
carry IP traffic, care must be taken to address the specific 
characteristics of these technologies within the header compression 
algorithms. Legacy header compression schemes, such as those defined 
in [RFC2507] and [RFC2508], have been shown to perform inadequately 
over links where both the lossy behavior and the round-trip times are 
non-negligible, such as those observed, for example, in wireless 
links and IP tunnels. 


In addition, a header compression scheme should handle the often non- 
trivial residual errors, i.e., where the lower layer may pass a 
packet that contains undetected bit errors to the decompressor. It 
should also handle loss and reordering before the compression point, 
as well as on the link between the compression and decompression 
points [RFC4224]. 


The Robust Header Compression (ROHC) protocol provides an efficient, 
flexible, and future-proof header compression concept. It is 
designed to operate efficiently and robustly over various link 
technologies with different characteristics. 
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RFC 3095 [RFC3095] defines the ROHC framework along with an initial 


set of compression profiles. To improve and simplify the 
specification, the framework and the profiles’ parts have been split 
into separate documents. This document explicitly defines the ROHC 


framework, but it does not modify or update the definition of the 
framework specified by RFC 3095; both documents can be used 
independently of each other. This also implies that implementations 
based on either definition will be compatible and interoperable with 
each other. However, it is the intent to let this specification 
replace RFC 3095 as the base specification for all profiles defined 
in the future. 


This document fixes one interoperability issue that was erroneously 
introduced in RFC 4995. The fix for this issue is located in 

Section 5.2.4.1 and clarifies the interpretation of the Size field in 
ROHC feedback. 


2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2.1. Acronyms 


This section lists most acronyms used for reference. 


ACK Acknowledgment. 

CID Context Identifier. 

CO Compressed Packet Format. 

CRC Cyclic Redundancy Check. 

IR Initialization and Refresh. 

IR-DYN Initialization and Refresh, Dynamic part. 
LSB Least Significant Bit. 

MRRU Maximum Reconstructed Reception Unit. 

MSB Most Significant Bit. 

MSN Master Sequence Number. 


NACK Negative Acknowledgment. 
ROHC RObust Header Compression. 


2.2.  ROHC Terminology 
Context 
The context of the compressor is the state it uses to compress a 
header. The context of the decompressor is the state it uses to 


decompress a header. Either of these or the two in combination 
are usually referred to as "context", when it is clear which is 
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intended. The context contains relevant information from previous 
headers in the packet flow, such as static fields and possible 
reference values for compression and decompression. Moreover, 


additional information describing the packet flow is also part of 
the context, for example, information about the change behavior of 
fields (e.g., the IP Identifier behavior, or the typical inter- 
packet increase in sequence numbers and timestamps). 


Context damage 


When the context of the decompressor is not consistent with the 
context of the compressor, decompression may fail to reproduce the 
original header. This situation can occur when the context of the 
decompressor has not been initialized properly or when packets 
have been lost or damaged between the compressor and decompressor. 


Packets that cannot be decompressed due to inconsistent contexts 
are said to be lost due to context damage. Packets that are 
decompressed but contain errors due to inconsistent contexts are 
said to be damaged due to context damage. 


Context repair mechanisms 


Mechanisms used to resynchronize the contexts -- an important task 
since context damage causes loss propagation. Examples of such 
mechanisms are NACK-based mechanisms, and the periodic refreshes 
of important context information, usually done in unidirectional 
operation. There are also mechanisms that can reduce the context 
inconsistency probability, for example, repetition of the same 
type of information in multiple packets and CRCs that protect 
context-updating information. 


CRC-8 validation 
The validation of the integrity against bit error(s) in a received 
IR and IR-DYN header using the 8-bit CRC included in the IR/IR-DYN 
header. 

CRC verification 
The verification of the result of a decompression attempt using 


the 3-bit CRC or 7-bit CRC included in the header of a compressed 
packet format. 
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Damage propagation 


Delivery of incorrect decompressed headers due to context damage, 
such as errors in (i.e., loss of or damage to) previous header (s) 
or feedback. 


Error detection 


Detection of errors by lower layers. If error detection is not 
perfect, there will be residual errors. 


Error propagation 
Damage propagation or loss propagation. 
ROHC profile 


A compression protocol that specifies how to compress specific 
header combinations. A ROHC profile may be tailored to handle a 
specific set of link characteristics, e.g., loss characteristics, 
reordering between compression points, etc. ROHC profiles provide 
the details of the header compression framework defined in this 
document, and each compression profile is associated with a unique 
ROHC profile identifier [ROHC-ids]. When setting up a ROHC 
channel, the set of profiles supported by both endpoints of the 
channel is negotiated, and when initializing new contexts, a 
profile identifier from this negotiated set is used to associate 
each compression context with one specific profile. 


Link 
A physical transmission path that constitutes a single IP hop. 
Loss propagation 


Loss of headers, due to errors in (i.e., loss of or damage to) 
previous header(s) or feedback. 


Packet flow 
A sequence of packets where the field values and change patterns 
of field values are such that the headers can be compressed using 
the same context. 


Residual error 


Error introduced during transmission and not detected by lower- 
layer error detection schemes. 
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ROHC channel 


A logical unidirectional point-to-point channel carrying ROHC 
packets from one compressor to one decompressor, optionally 
carrying ROHC feedback information on the behalf of another 
compressor-decompressor pair operating on a separate ROHC channel 
in the opposite direction. See also [RFC3759]. 


This document also makes use of the conceptual terminology defined by 
"ROHC Terminology and Channel Mapping Examples", RFC 3759 [RFC3759]. 


3. Background (Informative) 


This section provides a background to the subject of header 
compression. The fundamental ideas are described together with a 
discussion about the history of header compression schemes. The 
motivations driving the development of the various schemes are 
discussed and their drawbacks identified, thereby providing the 
foundations for the design of the ROHC framework and profiles 
[RFC3095]. 


3.1. Header Compression Fundamentals 


Header compression is possible because there is significant 
redundancy between header field values within packets, but in 
particular between consecutive packets belonging to the same flow. 

On the path end-to-end, the entire header information is necessary 
for all packets in the flow, but over a single link, some of this 
information becomes redundant and can be reduced, as long as it is 
transparently recovered at the receiving end of the link. The header 
Size can be reduced by first sending field information that is 
expected to remain static for (at least most of) the lifetime of the 
packet flow. Further compression is achieved for the fields carrying 
information that changes more dynamically by using compression 
methods tailored to their respective assumed change behavior. 


To achieve compression and decompression, some necessary information 
from past packets is maintained in a context. The compressor and the 
decompressor update their respective contexts upon certain, not 
necessarily synchronized, events.  Impairment events may lead to 
inconsistencies in the decompressor context (i.e., context damage), 
which in turn may cause incorrect decompression. A Robust Header 
Compression scheme needs mechanisms to minimize the possibility of 
context damage, in combination with mechanisms for context repair. 
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3.2. A Short History of Header Compression 


The first header compression scheme, compressed TCP (CTCP) [RFC1144], 
was introduced by Van Jacobson. CTCP, also often referred to as VJ 
compression, compresses the 40 octets of the TCP/IP header down to 4 
octets.  CTCP uses delta encoding for sequentially changing fields. 
The CTCP compressor detects transport-level retransmissions and sends 
a header that updates the entire context when they occur. This 
repair mechanism does not require any explicit signaling between the 
compressor and decompressor. 


A general IP header compression scheme, IP header compression 
[RFC2507], improves somewhat on CTCP. IP header compression (IPHC) 
can compress arbitrary IP, TCP, and UDP headers. When compressing 
non-TCP headers, IPHC does not use delta encoding and is robust. The 
repair mechanism of CTCP is augmented with negative acknowledgments, 
called CONTEXT STATE messages, which speed up the repair. This 
context repair mechanism is thus limited by the round-trip time of 
the link.  IPHC does not compress RTP headers. 


CRTP [RFC2508] is an RTP extension to IPHC. CRIP compresses the 40 
octets of IPv4/UDP/RTP headers to a minimum of 2 octets when the UDP 
Checksum is not enabled. If the UDP Checksum is enabled, the minimum 
CRTP header is 4 octets. 


On lossy links with long round-trip times, CRTP does not perform well 
[CRTP-eval]. Each packet lost over the link causes decompression of 
several subsequent packets to fail, because the context becomes 
invalidated during at least one link round-trip time from the lost 
packet. Unfortunately, the large headers that CRTP sends when 
updating the context waste additional bandwidth. 


CRTP uses a local repair mechanism known as TWICE, which was 
introduced by IPHC. TWICE derives its name from the observation that 
when the flow of compressed packets is regular, the correct guess 
when one packet is lost between the compression points is to apply 
the update in the current packet twice. While TWICE improves CRTP 
performance significantly, [CRTP-eval] also found that even with 
TWICE, CRIP doubled the number of lost packets. 


An enhanced variant of CRTP, called eCRTP [RFC3545], means to improve 
the robustness of CRTP in the presence of reordering and packet 
losses, while keeping the protocol almost unchanged from CRTP. As a 
result, eCRTP does provide better means to implement some degree of 
robustness, albeit at the expense of additional overhead, leading to 
a reduction in compression efficiency in comparison to CRTP. 
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4. Overview of ROHC (Informative) 
4.1. General Principles 


As mentioned earlier, header compression is possible per-link due to 
the fact that there is much redundancy between header field values 
within packets, and especially between consecutive packets belonging 
to the same flow. To utilize these properties for header 
compression, there are a few essential steps to consider. 


The first step consists of identifying and grouping packets together 
into different "flows", so that packet-to-packet redundancy is 
maximized in order to improve the compression ratio.  Grouping 
packets into flows is usually based on source and destination host 
(IP) addresses, transport protocol type (e.g., UDP or TCP), process 
(port) numbers, and potentially additional unique application 
identifiers, such as the synchronization source (SSRC) in RTP 
[RFC3550]. The compressor and decompressor each establish a context 
for the packet flow and identify the context with a Context 
Identifier (CID) included in each compressed header. 


The second step is to understand the change patterns of the various 
header fields. On a high level, header fields fall into one of the 
following classes: 


INFERRED These fields contain values that can be inferred from 
other fields or external sources; for example, the size 
of the frame carrying the packet can often be derived 
from the link-layer protocol, and thus does not have to 
be transmitted by the compression scheme. 


STATIC Fields classified as STATIC are assumed to be constant 
throughout the lifetime of the packet flow. The value 
of each field is thus only communicated initially. 


STATIC-DEF Fields classified as STATIC-DEF are used to define a 
packet flow as discussed above. Packets for which 
respective values of these fields differ are treated as 
belonging to different flows. These fields are in 
general compressed as STATIC fields. 


STATIC-KNOWN Fields classified as STATIC-KNOWN are expected to have 
well-known values, and therefore their values do not 
need to be communicated. 
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CHANGING These fields are expected to vary randomly, either 
within a limited value set or range, or in some other 
manner. CHANGING fields are usually handled in more 
sophisticated ways based on a more detailed 
classification of their expected change patterns. 


Finally, the last step is to choose the encoding method(s) that will 
be applied onto different fields based on classification. The 
encoding methods, in combination with the identified field behavior, 
provide the input to the design of the compressed header formats. 

The analysis of the probability distribution of the identified change 
patterns then provides the means to optimize the packet formats, 
where the most frequently occurring change patterns for a field 
should be encoded within the most efficient format(s). 


However, compression efficiency has to be traded against two other 
properties: the robustness of the encoding to losses and errors 
between the compressor and the decompressor, and the ability to 
detect and cope with errors in the decompression process. 


4.2. Compression Efficiency, Robustness, and Transparency 
The performance of a header compression protocol can be described 
with three parameters: its compression efficiency, its robustness, 
and its compression transparency. 


Compression efficiency 


The compression efficiency is determined by how much the average 
header size is reduced by applying the compression protocol. 


Robustness 


A robust protocol tolerates packet losses, residual bit errors, 
and out-of-order delivery on the link over which header 
compression takes place, without losing additional packets or 
introducing additional errors in decompressed headers. 


Compression transparency 
The compression transparency is a measure of the extent to which 
the scheme maintains the semantics of the original headers. If 


all decompressed headers are bitwise identical to the 
corresponding original headers, the scheme is transparent. 
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4.3. Developing the ROHC Protocol 


The challenge in developing a header compression protocol is to 
conciliate compression efficiency and robustness while maintaining 
transparency, as increasing robustness will always come at the 
expense of a lower compression efficiency, and vice versa. The 
scheme should also be flexible enough in its design to minimize the 
impacts from the varying round-trip times and loss patterns of links 
where header compression will be used. 


To achieve this, the header compression scheme must provide 
facilities for the decompressor to verify decompression and detect 
potential context damage, as well as context recovery mechanisms such 
as feedback. Header compression schemes prior to the ones developed 
by the Robust Header Compression (ROHC) Working Group (WG) were not 
designed with the above high-level objectives in mind. 


The ROHC WG has developed header compression solutions to meet the 
needs of present and future link technologies. While special 
attention has been put towards meeting the more stringent 
requirements stemming from the characteristics of wireless links, the 
results are equally applicable to many other link technologies. 


"RObust Header Compression (ROHC): Framework and four profiles: RTP, 
UDP, ESP, and uncompressed" [RFC3095] was published in 2001, as the 
first output of the ROHC WG.  ROHC is a general and extendable 
framework for header compression, on top of which profiles can be 
defined for compression of different protocols headers. RFC 3095 
introduced a number of new compression techniques, and was successful 
at living up to the requirements placed on it, as described in 
[RFC3096]. 


Interoperability testing of RFC 3095 confirms the capabilities of 
ROHC to meet its purposes, but feedback from implementers has also 
indicated that the protocol specification is complex and sometimes 
obscure. Most importantly, a clear distinction between framework and 
profiles is not obvious in [RFC3095], which also makes development of 
additional profiles troublesome. This document therefore aims at 
explicitly specifying the ROHC framework, while a companion document 
[RFC5225] specifies revised versions of the compression profiles of 
RFC 3095. 
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4.4. Operational Characteristics of the ROHC Channel 


Robust header compression can be used over many types of link 
technologies. The ROHC framework provides flexibility for profiles 
to address a wide range of applications, and this section lists some 
of the operational characteristics of the ROHC channel (see also 
[RFC3759]). 


Multiplexing over a single logical channel 


The ROHC channel provides a mechanism to identify a context within 
the general ROHC packet format. The CID makes it possible for a 
logical channel that supports ROHC to transport multiple header- 
compressed flows, while still making it possible for a channel to 
be dedicated to one single packet flow without any CID overhead. 
More specifically, ROHC uses a distinct CID space per logical 
channel, and the CID can be omitted for one of the flows over the 
ROHC channel when configured to use a small CID space. 


Establishment of channel parameters 
A link layer defining support for the ROHC channel must provide 
the means to establish header compression channel parameters (see 
Section 5.1). This can be achieved through a negotiation 
mechanism, static provisioning, or some out-of-band signaling. 


Packet type identification 


The ROHC channel defines a packet type identifier space, and puts 
restrictions with respect to the use of a number of identifiers 


that are common for all ROHC profiles. Identifiers that have no 
restrictions, i.e., identifiers that are not defined by this 
document, are available to each profile. The identifier is part 


of each compressed header, and this makes it possible for the link 
that supports the ROHC channel to allocate one single link-layer 
payload type for ROHC. 


Out-of-order delivery between compression endpoints 


Each profile defines its own level of robustness, including 
tolerance to reordering of packets before but especially between 
compression endpoints, if any. 


For profiles specified in [RFC3095], the channel between the 
compressor and decompressor is required to maintain in-order 
delivery of the packets; i.e., the definition of these profiles 
assumes that the decompressor always receives packets in the same 
order as the compressor sent them. The impacts of reordering on 
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the performance of these profiles are described in [RFC4224]. 
However, reordering before the compression point is handled, i.e., 
these profiles make no assumption that the compressor will receive 
packets in order. 


For the ROHCv2 profiles specified in [RFC5225], their definitions 
assume that the decompressor can receive packets out of order, 
i.e., not in the same order that the compressor sent them. 
Reordering before the compression point is also dealt with. 


Duplication of packets 


The link supporting the ROHC channel is required to not duplicate 
packets (however, duplication of packets can occur before they 
reach the compressor; i.e., there is no assumption that the 
compressor will receive only one copy of each packet). 


Framing 


The link layer must provide framing that makes it possible to 
distinguish frame boundaries and individual frames. 


Error detection/protection 


ROHC profiles should be designed to cope with residual errors in 
the headers delivered to the decompressor.  CRCs are used to 
detect decompression failures and to prevent or reduce damage 
propagation. However, it is recommended that lower layers deploy 
error detection for ROHC headers and that ROHC headers with high 
residual error rates not be delivered. 


4.5. Compression and Master Sequence Number (MSN) 


Compression of header fields is based on the establishment of a 
function to a sequence number, called the master sequence number 
(MSN). This function describes the change pattern of the field with 
respect to a change in the MSN. 


Change patterns include, for example, fields that increase 
monotonically or by a small value, fields that seldom change, and 
fields that remain unchanging for the entire lifetime of the packet 
flow, in which case the function to the MSN is equivalent to a 
constant value. 


The compressor first establishes functions for each of the header 


fields, and then reliably communicates the MSN. When the change 
pattern of the field does not match the established function, i.e., 
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the existing function gives a result that is different from the field 
in the header being compressed, additional information can be sent to 
update the parameters of that function. 


The MSN is defined per profile. It can be either derived directly 
from one of the fields of the protocol being compressed (e.g., the 
RTP SN [RFC5225]), or it can be created and maintained by the 
compressor (e.g., the MSN for compression of UDP in profile 0x0102 
[RFC5225] or the MSN in ROHC-TCP [RFC4996]). 


4.6. Static and Dynamic Parts of a Context 


A compression context can be conceptually divided into two different 
parts, the static context and the dynamic context, each based on the 
properties of the fields that are being compressed. 


The static part includes the information necessary to compress and 
decompress the fields whose change behavior is classified as STATIC, 
STATIC-KNOWN, or STATIC-DEF (as described in Section 4.1 above). 


The dynamic part includes the state maintained for all the other 
fields, i.e., those that are classified as CHANGING. 


5. The ROHC Framework (Normative) 


This section normatively defines the parts common to all ROHC 
profiles, i.e., the framework. The framework specifies the 
requirements and functionality of the ROHC channel, including how to 
handle multiple compressed packet flows over the same channel. 


Finally, this section specifies encoding methods used in the packet 
formats that are common to all profiles. These encoding methods may 
be reused within profile specifications for encoding fields in 
profile-specific parts of a packet format, without requiring their 
redefinition. 


5.1. The ROHC Channel 


5.1.1. Contexts and Context Identifiers 


Associated with each compressed flow is a context. The context is 
the state that the compressor and the decompressor maintain in order 
to correctly compress or decompress the headers of the packet in the 
flow. Each context is identified using a CID. 
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A context is considered to be a new context when the CID is 
associated with a profile for the first time since the creation of 
the ROHC channel, or when the CID gets associated from the reception 
of an IR (this does not apply to the IR-DYN) with a different profile 
than the profile in the context. 


Context information is conceptually kept in a table. The context 
table is indexed using the CID, which is sent along with compressed 
headers and feedback information. 


The CID space can be either small, which means that CIDs can take the 
values 0 through 15, or large, which means that CIDs take values 
between 0 and 2%14 - 1 = 16383. Whether the CID space is large or 
small MUST be established, possibly by negotiation, before any 
compressed packet may be sent over the ROHC channel. 


The CID space is distinct for each channel, i.e., CID 3 over channel 
A and CID 3 over channel B do not refer to the same context, even if 
the endpoints of A and B are the same nodes. In particular, CIDs for 
any pair of ROHC channels are not related (two associated ROHC 
channels serving as feedback channels for one another do not even 
need to have CID spaces of the same size). 


5.1.2. Per-Channel Parameters 


The ROHC channel is based on a number of parameters that form part of 
the established channel state and the per-context state. The state 
of the ROHC channel MUST be established before the first ROHC packet 
may be sent, which may be achieved using negotiation protocols 
provided by the link layer (see also [RFC3241], which describes an 
option for negotiation of ROHC parameters for PPP). This section 
describes some of this channel state information in an abstract way: 


LARGE CIDS: Boolean; if false, the small CID representation (0 octets 
or 1 prefix octet, covering CID 0 to 15) is used; if true, the large 
CID representation (1 or 2 embedded CID octets covering CID 0 to 
16383) is used. See also Section 5.1.1 and Section 5.2.1.3. 


MAX_CID: Non-negative integer; highest CID number to be used by the 
compressor (note that this parameter is not coupled to, but in effect 
further constrained by, LARGE_CIDS). This value represents an 
agreement by the decompressor that it can provide sufficient memory 
resources to host at least MAX _CID+1 contexts; the decompressor MUST 
maintain established contexts within this space until either the CID 
gets re-used by the establishment of a new context, or until the 
channel is taken down. 
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PROFILES: Set of non-negative integers, where each integer indicates 
a profile supported by both the compressor and the decompressor. A 
profile is identified by a 16-bit value, where the 8 LSB bits 
indicate the actual profile, and the 8 MSB bits indicate the variant 
of that profile. The ROHC compressed header format identifies the 
profile used with only the 8 LSB bits; this means that if multiple 
variants of the same profile are available for a ROHC channel, the 
PROFILES set after negotiation MUST NOT include more than one variant 
of the same profile. The compressor MUST NOT compress using a 
profile that is not in PROFILES. 


FEEDBACK_FOR: Optional reference to a ROHC channel in the opposite 
direction between the same compression endpoints. If provided, this 
parameter indicates to which other ROHC channel any feedback sent on 
this ROHC channel refers (see [RFC3759]). 


MRRU: Non-negative integer. Maximum Reconstructed Reception Unit. 
This is the size of the largest reconstructed unit in octets that the 
decompressor is expected to reassemble from segments (see 

Section 5.2.5). This size includes the segmentation CRC. If MRRU is 
negotiated to be 0, segmentation MUST NOT be used on the channel, and 
received segments MUST be discarded by the decompressor. 


5.1.3. Persistence of Decompressor Contexts 


As part of the negotiated channel parameters, the compressor and 
decompressor have through the MAX_CID parameter agreed on the highest 
context identification (CID) number to be used. By agreeing on the 
MAX_CID, the decompressor also agrees to provide memory resources to 
host at least MAX _CID+1 contexts, and an established context with a 
CID within this negotiated space SHOULD be kept by the decompressor 
until either the CID gets re-used, or the channel is taken down or 
re-negotiated. 


5.2.  ROHC Packets and Packet Types 


This section uses the following convention in the diagrams when 
representing various ROHC packet types, formats, and fields: 


- colons ":" indicate that the part is optional 
- slashes "/" indicate variable length 


The ROHC packet type indication scheme has been designed to provide 
optional padding, a feedback packet type, an optional Add-CID octet 
(which includes 4 bits of CID), and a simple segmentation and 
reassembly mechanism. 
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The following packet types are reserved at the ROHC framework level: 


11100000 : Padding 
1110nnnn : Add-CID octet (nnnn=CID with values 0x1 through OxF) 


11110 : Feedback 
11111000 : IR-DYN packet 
1111110 : IR packet 
1111111 : Segment 


Other packet types can be defined and used by individual profiles: 


0 : available (not reserved by ROHC framework) 
10 : available (not reserved by ROHC framework) 
110 : available (not reserved by ROHC framework) 
1111101 : available (not reserved by ROHC framework) 
11111001 : available (not reserved by ROHC framework) 


5.2.1. General Format of ROHC Packets 


A ROHC packet has the following general format: 


Padding 


Feedback 


Header 


Payload 


Padding: Any number (zero or more) of padding octets, where the 
format of a padding octet is as defined in Section 5.2.1.1. 


Feedback: Any number (zero or more) of feedback elements, where the 
format of a feedback element is as defined in Section 5.2.4.1. 


Header: Either a profile-specific CO header (see Section 5.2.1.3), an 
IR or IR-DYN header (see Section 5.2.2), or a ROHC Segment (see 
Section 5.2.5). There can be at most one Header in a ROHC packet, 
but it may also be omitted (if the packet contains Feedback only). 


Payload: Corresponds to zero or more octets of payload from the 
uncompressed packet, starting with the first octet in the 
uncompressed packet after the last header compressible by the current 
profile. 


At least one of Feedback or Header MUST be present. 
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5.2.1.1. Format of the Padding Octet 
Padding octet: 


Qr Mt um Wow a Sc 
T-——---—4---—4---4---—4---4---4---— 
|: udis e3be 80s De Chop SORS _, 1074 
+---+---+---4+---+---+---4+---4+---+ 


Note: The Padding octet MUST NOT be interpreted as an Add-CID octet 


for CID 0. 
5.2.1.2. Format of the Add-CID Octet 
Add-CID octet: 
0 1 2 3 4 5 6 7 
+---+---+---+---+---+---+---+---+ 


ie: eee: ees ee | CID 
+---+---+---+---+---+---+---+---+ 


CID: 0x1 through OxF indicates CIDs 1 through 15. 


Note: The Padding octet looks like an Add-CID octet for CID 0. 


5.2.1.3. General Format of Header 


All ROHC packet types have the following general Header format: 


0 x-1 x 7 


Add-CID octet 


+--- --- --- --- cl-2-4--- --- ---X 
| type indication | body | 
+--- --- --- --- ---4+--- --- ---+ 
/ 0, 1, or 2 octets of CID / 


4-——4---4---4---4---4---4---4---—4 
/ body / 
4-——4---—4---—4---—4---4---4---4---—4 


type indication: ROHC packet type. 


if CID 1-15 and small CIDs 


1 octet (8-x bits of body) 


1 or 2 octets if large CIDs 


variable length 


body: Interpreted according to the packet type indication and CID 
information, as defined by individual profiles. 
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Thus, the header either starts with a packet type indication or has a 
packet type indication immediately following an Add-CID octet. 


When the ROHC channel is configured with a small CID space: 


[e If an Add-CID immediately precedes the packet type indication, 
the packet has the CID of the Add-CID; otherwise, it has CID 0. 


(0) A small CID with the value 0 is represented using zero bits; 
therefore, a flow associated with CID 0 has no CID overhead in 
the compressed header. In such case, Header starts with a packet 
type indication. 


O A small CID with a value from 1 to 15 is represented using the 
Add-CID octet as described above. The Header starts with the 
Add-CID octet, followed by a packet type indication. 


[e There is no large CID in the Header. 
When the ROHC channel is configured with a large CID space: 


fe) The large CID is always present and is represented using the 
encoding scheme of Section 5.3.2, limited to two octets. In this 
case, the Header starts with a packet type indication. 


5.2.2. Initialization and Refresh (IR) Packet Types 


IR packet types contain a profile identifier, which determines how 
the rest of the header is to be interpreted. They also associate a 
profile with a context. The stored profile parameter further 
determines the syntax and semantics of the packet type identifiers 
and packet types used with a specific context. 


The IR and IR-DYN packets always update the context for all context- 
updating fields carried in the header. They never clear the context, 
except when initializing a new context (see Section 5.1.1), or unless 
the profile indicated in the Profile field specifies otherwise. 


5.2.2.1.  ROHC IR Header Format 
The IR header associates a CID with a profile, and typically also 


initializes the context. It can typically also refresh all (or parts 
of) the context. For IR, Header has the following general format: 
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0 ii 2 3 4 D 6 7 


: Add-CID octet : if CID 1-15 and small CID 
4R--——4---4---4---4---4---4---4---4 

| 1, 1 1 1 1 1 0 |x | IR type octet 
+---+---+---+---+---+---+---+---+ 


/ 0-2 octets of CID / 1 or 2 octets if large CIDs 


4+---4---4---4---+---+4---+---+---+ 


| Profile | 1 octet 
4-——4---—4---4---4---4---4---4---—4 
| CRC | 1 octet 


R---—4R---4R---4---4---4---4---4---—4 


/ profile-specific information / variable length 


R--—4R---4---4---4---4---4---4---—4 


x: Profile-specific information.  Interpreted according to the 
profile indicated in the Profile field of the IR header. 


Profile: The profile associated with the CID. In the IR header, the 
profile identifier is abbreviated to the 8 least significant bits 
(see Section 5.1.2). 


CRC: 8-bit CRC (see Section 5.3.1.1). 


Profile-specific information: The content of this part of the IR 
header is defined by the individual profiles. It is interpreted 
according to the profile indicated in the Profile field. 


5.2.2.2.  ROHC IR-DYN Header Format 


In contrast to the IR header, the IR-DYN header can never initialize 
a non-initialized context. However, it can redefine what profile is 
associated with a context, if the profile indicated in the IR-DYN 
header allows this. Thus, this packet type is also reserved at the 
framework level. The IR-DYN header typically also initializes or 
refreshes parts of a context. For IR-DYN, Header has the following 
general format: 
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0 ii 2 3 4 D 6 7 


E Add-CID octet : if CID 1-15 and small CID 
T-——4---4---4---4---4---4---4---4 

| 1 1 1 1 1 0 0 0 | IR-DYN type octet 
Tq-—-—4---4---4---4---4---4---4---4 


/ 0-2 octets of CID / 1 or 2 octets if large CIDs 


R---—4R---4R---4---4---4---4---4---—4 


| Profile | 1 octet 
4-——4---—4---4---4---4---4---4---—4 
| CRC | 1 octet 


R---—4R---4R---4---4---4---4---4---—4 


/ profile-specific information / variable length 


R---—4R---4---4---4---4---4---4---—4 


Profile: The profile associated with the CID. This is abbreviated in 
the same way as in IR packets. 


CRC: 8-bit CRC (see Section 5.3.1.1). 


Profile-specific information: The content of this part of the IR-DYN 
header is defined by the individual profiles. It is interpreted 
according to the profile indicated in the Profile field. 


5.2.3. | ROHC Initial Decompressor Processing 


Initially, all contexts are in no context state. Thus, all packets 
referencing a non-initialized context, except packets that have 
enough information on the static fields, cannot be decompressed by 
the decompressor. 


When the decompressor receives a packet of type IR, the profile 
indicated in the IR packet determines how it is to be processed. 


o If the 8-bit CRC fails to verify the integrity of the header, the 
packet MUST NOT be decompressed and delivered to upper layers. If 
a profile is indicated in the context, the logic of that profile 
determines what, if any, feedback is to be sent. If no profile is 
noted in the context, the logic used to determine what, if any, 
feedback to send is up to the implementation. However, it may be 
suitable to take no further actions, as any part of the IR header 
covered by the CRC may have caused the failure. 
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When the decompressor receives a packet of type IR-DYN, the profile 
indicated in the IR-DYN packet determines how it is to be processed. 


o If the 8-bit CRC fails to verify the integrity of the header, the 
packet MUST NOT be decompressed and delivered to upper layers. If 
a profile is indicated in the context, the logic of that profile 
determines what, if any, feedback is to be sent. If no profile is 
noted in the context, the logic used to determine what, if any, 
feedback to send is up to the implementation. However, it may be 
suitable to take no further actions, as any part of the IR-DYN 
header covered by the CRC may have caused the failure. 


o If the context has not already been initialized, the packet MUST 
NOT be decompressed and delivered to upper layers. The logic of 
the profile indicated in the IR-DYN header (if verified by the 
8-bit CRC), determines what, if any, feedback is to be sent. 


If a parsing error occurs for any packet type, the decompressor MUST 
discard the packet without further processing. For example, a CID 
field is present in the compressed header when the large CID space is 
used for the ROHC channel, and the field is coded using the self- 
describing variable-length encoding of Section 5.3.2; if the field 
starts with 110 or 111, this would generate a parsing error for the 
decompressor because this field must not be encoded with a size 
larger than 2 octets. 


It is RECOMMENDED that profiles disallow the decompressor to make a 
decompression attempt for packets carrying only a 3-bit CRC after it 
has invalidated some or all of the entire dynamic context, until a 
packet that contains sufficient information on the dynamic fields is 
received, decompressed, and successfully verified by a 7- or 8-bit 
CRC. 


5.2.4. ROHC Feedback 
Feedback carries information from the decompressor to the compressor. 
Feedback can be sent over a ROHC channel that operates in the same 
direction as the feedback. 
The general ROHC packet format allows transport of feedback using 
interspersion or piggybacking (see [RFC3759]), or a combination of 
both, over a ROHC channel. This is facilitated by the following 
properties: 


Reserved packet type: 


A feedback packet type is reserved at the framework level. The 
packet type can carry variable-length feedback information. 


Sandlund, et al. Standards Track [Page 23] 


RFC 5795 ROHC Framework March 2010 


CID information: 


The feedback information sent on a particular channel is passed 
to, and interpreted by, the compressor associated with feedback on 
that channel. Thus, each feedback element contains CID 
information from the channel for which the feedback is sent. The 
ROHC feedback scheme thus requires that a channel carries feedback 
to at most one compressor. How a compressor is associated with 
the feedback for a particular channel is outside the scope of this 
specification. See also [RFC3759]. 


Length information: 


The length of a feedback element can be determined by examining 
the first few octets of the feedback. This enables piggybacking 
of feedback, and also the concatenation of more than one feedback 
element in a packet. The length information thus decouples the 
decompressor from the associated same-side compressor, as the 
decompressor can extract the feedback information from the 
compressed header without parsing its content and hand over the 
extracted information. 


The association between compressor-decompressor pairs operating in 
opposite directions, for the purpose of exchanging piggyback and/or 
interspersed feedback, SHOULD be maintained for the lifetime of the 
ROHC channel. Otherwise, it is RECOMMENDED that the compressor be 
notified if the feedback channel is no longer available: the 
compressor SHOULD then restart compression by creating a new context 
for each packet flow, and SHOULD use a CID value that was not 
previously associated with the profile used to compress the flow. 


5.2.4.1.  ROHC Feedback Format 


ROHC defines three different categories of feedback messages: 
acknowledgment (ACK), negative ACK (NACK), and NACK for the entire 
context (STATIC-NACK). Other types of information may be defined in 
profile-specific feedback information. 


ACK: Acknowledges successful decompression of a packet. Indicates 
that the decompressor considers its context to be valid. 


NACK: Indicates that the decompressor considers some or all of the 
dynamic part of its context invalid. 


STATIC-NACK : Indicates that the decompressor considers its entire 
static context invalid, or that it has not been established. 


Sandlund, et al. Standards Track [Page 24] 


RFC 5795 ROHC Framework March 2010 


Feedback sent on a ROHC channel consists of one or more concatenated 
feedback elements, where each feedback element has the following 
format: 


0 1 2 3 4 5 6 7 
p--—4R---4R---4---4---4---4---4---—4 


| 1 1 1 1 o | Code feedback type 
+---4---+---4+---+---4+---+---+---+ 

: Size : if Code = 0 
+---4---+---4+---+---4+---+4+---+---+ 

: Add-CID octet : if for small CIDs and (CID != 0) 


4p-——4R---—4---—4---—4---—4---—4---—4---—4 
/ large CID / 1-2 octets if for large CIDs 
4-——4---—4---—4---—4---—4---—4---—4---—4 
/ FEEDBACK data / variable length 
4---4---4---4---4---4+---4+---4+---+ 

Code: 


0 indicates that a Size octet is present. 


1-7 indicates the total size of the FEEDBACK data field and the 
CID field (if any), in octets. 


Size: Indicates the total size of the FEEDBACK data field and the CID 
field (if any), in octets. 


FEEDBACK data: FEEDBACK-1 or FEEDBACK-2 (see below). 


CID information in a feedback element indicates the context for which 
feedback is sent. The LARGE_CIDS parameter that controls whether a 
large CID is present is taken from the channel state of the receiving 
compressor’s channel, not from the state of the channel carrying the 
feedback. 


The large CID field, if present, is encoded according to 
Section 5.3.2, and it MUST NOT be encoded using more than 2 octets. 


The FEEDBACK data field can have either of the following two formats: 
FEEDBACK-1: 
0 1 2 3 4 5 6 7 
4---—4---4---—4---4---4---4---4---4 


| profile-specific information 1 octet 
4---4---4---4---4---4---4---4---4 
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FEEDBACK-2: 


0 al 2 3 4 5 6 7 
+---+---+---+---+---+---+---+---+ 
|Acktype | | 
T---t4---—- profile-specific / at least 2 octets 
/ information | 
+---+---+---+---+---+---+---+---+ 


0 = ACK 

1 = NACK 

2 = STATIC-NACK 

3 is reserved (MUST NOT be used. Otherwise unparsable.) 


Acktype: 


5.2.5. ROHC Segmentation 


ROHC defines a simple segmentation protocol. The compressor may 
perform segmentation, e.g., to accommodate packets that are larger 
than a specific size configured for the channel. 


5.2.5.1. Segmentation Usage Considerations 


The ROHC segmentation protocol is not particularly efficient. It is 
not intended to replace link-layer segmentation functions; these 
SHOULD be used whenever available and efficient for the task at hand. 


The ROHC segmentation protocol has been designed with an assumption 
of in-order delivery of packets between the compressor and the 
decompressor, using only a CRC for error detection, and no sequence 
numbers. If in-order delivery cannot be guaranteed, ROHC 
segmentation MUST NOT be used. 


The segmentation protocol also assumes that all segments of a ROHC 
packet corresponding to one context are received without interference 
from other ROHC packets over the channel, including any ROHC packet 
corresponding to a different context. Based on this assumption, 
segments do not carry CID information, and therefore cannot be 
associated with a specific context until all segments have been 
received and the whole unit has been reconstructed. 


5.2.5.2. Segmentation Protocol 


ROHC segmentation is applied to the combination of the Header and the 
Payload fields of the ROHC packet, as defined in Section 5.2.1. 
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Segment format: 


0 1 2 3 4 5 6 7 
+---+---+---+---+---+---+---+---+ 
| 1 1 1 1 1 1 1 | F | segment type 
+---+---+---+---+---+---+---+---+ 
/ Segment / variable length 
+---+---+---+---+---+---+---+---+ 


F: Final bit. If set, it indicates that this is the last segment of 
a reconstructed unit. 


Padding and/or Feedback may precede the segment type octet. There is 
no per-segment CID, but CID information is of course part of the 
reconstructed unit. The reconstructed unit MUST NOT contain padding, 
segments, or feedback. 


When a final segment is received, the decompressor reassembles the 
segment carried in this packet and any non-final segments that 
immediately preceded it into a single reconstructed unit, in the 
order they were received. All segments for one reconstructed unit 
have to be received consecutively and in the correct order by the 
decompressor. If a non-segment ROHC packet directly follows a non- 
final segment, the reassembly of the current reconstructed unit is 
aborted and the decompressor MUST discard the non-final segments so 
far received on this channel. 


Reconstructed unit: 


0 a 2 3 4 5 6 7 
+---4---4---4---+4---+---+---+---+ 


/ Header / 
4---4---4---4---4---4---4---4---4 
: Payload : 
4-—--4---4---4---4---4---4---4---4 
/ CRC / 4 octets 


+---4---+---4+---+---4+---+---+---+ 
Header: See Section 5.2.1 
Payload: See Section 5.2.1 


CRC: 32-bit CRC computed using the polynomial of Section 5.3.1.4 


Sandlund, et al. Standards Track [Page 27] 


RFC 5795 ROHC Framework March 2010 


If the reconstructed unit is 4 octets or less, or if the CRC fails, 
or if it is larger than the channel parameter MRRU (see 

Section 5.1.2), the reconstructed unit MUST be discarded by the 
decompressor. If the CRC succeeds, the reconstructed unit can be 
further processed. 


5.3. General Encoding Methods 
5.3.1. Header Compression CRCs, Coverage, and Polynomials 


This section describes how to calculate the CRCs used by ROHC. For 
all CRCs, the algorithm used to calculate the CRC is the same as the 
one used in [RFC1662], defined in Appendix A of this document, with 
the polynomials specified in subsequent sections. 


5.3.1.1. 8-bit CRC in IR and IR-DYN Headers 


The coverage for the 8-bit CRC in the IR and IR-DYN headers is 
profile-dependent, but it MUST cover at least the initial part of the 
header ending with the Profile field, including the CID or an Add-CID 
octet. Feedback and padding are not part of Header (Section 5.2.1) 
and are thus not included in the CRC calculation. As a rule of thumb 
for profile specifications, any other information that initializes 
the decompressor context SHOULD also be covered by a CRC. 


More specifically, the 8-bit CRC does not cover only and entirely the 
original uncompressed header; therefore, it does not provide the 
means for the decompressor to verify a decompression attempt, or the 
means to verify the correctness of the entire decompressor context. 
However, when successful, it does provide enough robustness for the 
decompressor to update its context with the information carried 
within the IR or the IR-DYN header. 


The CRC polynomial for the 8-bit CRC is: 
C(x) = 1 + x + x^2 + x^8 


When computing the CRC, the CRC field in the header is set to zero, 
and the initial content of the CRC register is set to all 1’s. 


5.3.1.2. 3-bit CRC in Compressed Headers 
The 3-bit CRC in compressed headers is calculated over all octets of 
the entire original header, before compression, in the following 


manner. 


The initial content of the CRC register is set to all 1’s. 
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The polynomial for the 3-bit CRC is: 
C(x) = 1+ x + x^3 


The purpose of the 3-bit CRC is to provide the means for the 
decompressor to verify the outcome of a decompression attempt for 
small compressed headers, and to detect context damage based on 
aggregated probability over a number of decompression attempts. 
However, it is too weak to provide enough success guarantees from the 
decompression of one single header. Therefore, compressed headers 
carrying a 3-bit CRC are normally not suitable to perform context 
repairs at the decompressor; hence, profiles should refrain from 
allowing decompression of such a header when some or the entire 
decompressor context is assumed invalid. 


5.3.1.3. 77-bit CRC in Compressed Headers 


The 7-bit CRC in compressed headers is calculated over all octets of 
the entire original header, before compression, in the following 
manner. 


The initial content of the CRC register is set to all 1’s. 
The polynomial for the 7-bit CRC is: 
C(x) = 1 + x + x^2 + x^3 + x^6 + x^] 


The purpose of the 7-bit CRC is to provide the means for the 
decompressor to verify the outcome of a decompression attempt for a 
larger compressed header, and to provide enough protection to 
validate a context repair at the decompressor. The 7-bit CRC is 
strong enough to assume a repair to be successful from the 
decompression of one single header; hence, profiles may allow 
decompression of a header carrying a 7-bit CRC when some of the 
decompressor context is assumed invalid. 


5.3.1.4. 32-bit Segmentation CRC 
The 32-bit CRC is used by the segmentation scheme to verify the 
reconstructed unit, and it is thus calculated over the segmented 
unit, i.e., over the Header and the Payload fields of the ROHC 
packet. 


The initial content of the CRC register is set to all 1’s. 
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The polynomial for the 32-bit CRC is: 


C(x) = x^O + x41 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + 
x^ll + x^l2 + x*%16 + x^22 + x^23 4+ x^26 + x^32 


The purpose of the 32-bit CRC is to verify the reconstructed unit. 
5.3.2. Self-Describing Variable-Length Values 

The values of many fields and compression parameters can vary widely. 

To optimize the transfer of such values, a variable number of octets 


are used to encode them. The first few bits of the first octet 
determine the number of octets used: 


First bit is 0: 1 octet. 
7 bits transferred. 
Up to 127 decimal. 
Encoded octets in hexadecimal: 00 to 7F 


First bits are 10: 2 octets. 
14 bits transferred. 
Up to 16 383 decimal. 
Encoded octets in hexadecimal: 80 00 to BF FF 


First bits are 110: 3 octets. 
21 bits transferred. 
Up to 2 097 151 decimal. 
Encoded octets in hexadecimal: CO 00 00 to DF FF FF 


First bits are 111: 4 octets. 
29 bits transferred. 
Up to 536 870 911 decimal. 
Encoded octets in hexadecimal: EO 00 00 00 to FF FF FF FF 


5.4.  ROHC UNCOMPRESSED -- No Compression (Profile 0x0000) 


This section describes the uncompressed ROHC profile. The profile 
identifier for this profile is 0x0000. 


Profile 0x0000 provides a way to send IP packets without compressing 
them. This can be used for any packet for which a compression 
profile is not available in the set of profiles supported by the ROHC 
channel, or for which compression is not desirable for some reason. 
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After initialization, the only overhead for sending packets using 
Profile 0x0000 is the size of the CID. When uncompressed packets are 
frequent, Profile 0x0000 should be associated with a CID the size of 
zero or one octet. Profile 0x0000 SHOULD be associated with at most 
one CID. 


5.4.1. IR Packet 


The initialization and refresh packet (IR packet) for Profile 0x0000 
has the following Header format: 


0 1 2 3 4 5 6 7 


: Add-CID octet : if for small CIDs and (CID !- 0) 
+---4+---+---4+---+---4+---+---+---+ 
(i SR "po. o. Eo: r 0 res 
+---+4+---+---4+---+---4+---+4+---+---+ 


/ 0-2 octets of CID info / 1-2 octets if for large CIDs 


4+---4---4---4---+4---+4---+---+---+ 


| Profile = 0x00 | 1 octet 
4--—4---—4---4---4---4---4---4---4 
| CRC | 1 octet 


4+---4---4---4---4---+---+---+---+ 


res: MUST be set to zero; otherwise, the decompressor MUST discard 
the packet. 


Profile: 0x00 


CRC: 8-bit CRC, computed using the polynomial of Section 5.3.1.1. 
The CRC covers the first octet of the IR Header through the Profile 
octet of the IR Header, i.e., it does not cover the CRC itself. 
Neither does it cover any preceding Padding or Feedback, nor the 
Payload. 


For the IR packet, Payload has the following format: 


: (optional) 
f IP packet / variable length 


IP packet: An uncompressed IP packet may be included in the IR 
packet. The decompressor determines if the IP packet is present by 
considering the length of the IR packet. 
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5.4.2. Normal Packet 


A Normal packet is a normal IP packet plus CID information. For the 
Normal Packet, the following format corresponds to the Header and 
Payload (as defined in Section 5.2.1): 


0 1 2 3 4 5 6 7 


: Add-CID octet : if for small CIDs and (CID != 0) 
R-—-4---—4---4---4---4---4---4---— 
| | first octet of IP packet | 
+—---+---+---+---+---+---+---+--—-+ 


/ 0-2 octets of CID info / 1-2 octets if for large CIDs 


+---+---+---4+---+---+---+---4+---+ 
/ rest of IP packet / variable length 


4+---4---4---+4---+4---+---+---+---+ 


Note that the first octet of the IP packet starts with the bit 
pattern 0100 (IPv4) or 0110 (IPv6). This does not conflict with any 
reserved packet types. 


When the channel uses small CIDs, and profile 0x0000 is associated 
with a CID > 0, an Add-CID octet precedes the IP packet. When the 
channel uses large CIDs, the CID is placed so that it starts at the 
second octet of the combined Header/Payload format above. 


A Normal Packet may carry Padding and/or Feedback as any other ROHC 
packet, preceding the combined Header/Payload. 


5.4.3. Context Initialization 


The compressor initializes the static context associated with the 
UNCOMPRESSED profile by sending IR packets (see Section 5.4.1). 
During context initialization, it is RECOMMENDED that the compressor 
sends IR packets until it is reasonably confident that the 
decompressor has successfully received at least one IR packet. For 
example, this confidence can be based on feedback from the 
decompressor, or on knowledge of the characteristics of the link. 


The compressor SHOULD periodically transmit IR packets for a context 
associated with the UNCOMPRESSED profile, at least until it receives 


feedback from the decompressor for that context. The compressor MAY 
stop the periodic sending of IR packets once it has received 
feedback. 
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5.4.4. Decompressor Operation 


When an IR packet is received, the decompressor first validates its 
header using the 8-bit CRC. 


Oo If the header fails validation, the decompressor MUST NOT deliver 
the IP packet to upper layers. 


o If the header is successfully validated, the decompressor 


1. initializes the context if it has no valid context for the 
given CID already associated to the specified profile, 


2. delivers the IP packet to upper layers if present, 
3. MAY send an ACK. 


When any other packet is received while the decompressor has no 
context, it is discarded without further action. 


When a Normal packet is received and the decompressor has a valid 
context, the IP packet is extracted and delivered to upper layers. 


5.4.5. Feedback 


The only kind of feedback defined by Profile 0x0000 is ACK, using the 
FEEDBACK-1 format of Section 5.2.4.1, where the value of the profile- 
specific octet in the FEEDBACK-1 is 0 (zero). The FEEDBACK-2 format 
is thus not defined for Profile 0x0000. 


6. Overview of a ROHC Profile (Informative) 


The ROHC protocol consists of a framework part and a profile part. 
The framework defines the mechanisms common to all profiles, while 
the profile defines the compression algorithm and profile-specific 
packet formats. 


Section 5 specifies the details of the ROHC framework. This section 
provides an informative overview of the elements that make a profile 
Specification. The normative specification of individual profiles is 
outside the scope of this document. 


A ROHC profile defines the elements that build up the compression 
protocol. A ROHC profile consists of: 
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Packet formats: 


o Bits-on-the-wire 


The profile defines the layout of the bits for profile-specific 
packet types that it defines, and for the profile-specific 
parts of packet types common to all profiles (e.g., IR and IR- 
DYN). 


o Field encodings 


Bits and groups of bits from the packet format layout, referred 
to as Compressed fields, represent the result of an encoding 
method specific for that compressed field within a specific 
packet format. The profile defines these encoding methods. 


o Updating properties 


The profile-specific packet formats may update the state of the 
decompressor, and may do so in different ways. The profile 
defines how individual profile-specific fields, or entire 
profile-specific packet types, update the decompressor context. 


o Verification 


Packets that update the state of the decompressor are verified 

to prevent incorrect updates to the decompressor context. The 

profile defines the mechanisms used to verify the decompression 
of a packet. 


Context management: 


o Robustness logic 


Packets may be lost or reordered between the compressor and the 
decompressor. The profile defines mechanisms to minimize the 
impacts of such events and prevent damage propagation. 


o Repair mechanism 


Sandlund, 


Despite the robustness logic, impairment events may still lead 
to decompression failure(s), and even to context damage at the 
decompressor. The profile defines context repair mechanisms, 
including feedback logic if used. 
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IANA Considerations 


An IANA registry for "RObust Header Compression (ROHC) Profile 
Identifiers" [ROHC-ids] was created by RFC 3095 [RFC3095]. The 
assignment policy, as outlined by RFC 3095, is the following: 


The ROHC profile identifier is a non-negative integer. In many 
negotiation protocols, it will be represented as a 16-bit value. Due 
to the way the profile identifier is abbreviated in ROHC packets, the 
8 LSBs of the profile identifier have a special significance: Two 
profile identifiers with identical 8 LSBs should be assigned only if 
the higher-numbered one is intended to supersede the lower-numbered 
one. To highlight this relationship, profile identifiers should be 
given in hexadecimal (for example, as in 0x1234, which would 
supersede 0x0A34). 


Following the policies outlined in [RFC5226], the IANA policy for 
assigning new values for the profile identifier is Specification 
Required: values and their meanings must be documented in an RFC or 
in some other permanent and readily available reference, in 
sufficient detail that interoperability between independent 
implementations is possible. In the 8 LSBs, the range 0 to 127 is 
reserved for IETF standard-track specifications; the range 128 to 254 
is available for other specifications that meet this requirement 
(such as Informational RFCs). The LSB value 255 is reserved for 
future extensibility of the present specification. 
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The following profile identifiers have so far been allocated: 


Profile Identifier Usage Reference 
0x0000 ROHC uncompressed RFC 5795 
0x0001 ROHC RTP RFC 3095 
0x0002 ROHC UDP RFC 3095 
0x0003 ROHC ESP RFC 3095 
0x0004 ROHC IP RFC 3843 
0x0005 ROHC LLA RFC 3242 
0x0105 ROHC LLA with R-mode RFC 3408 
0x0006 ROHC TCP RFC 4996 
0x0007 ROHC RTP/UDP-Lite RFC 4019 
0x0008 ROHC UDP-Lite RFC 4019 
0x0101 ROHCv2 RTP RFC 5225 
0x0102 ROHCv2 UDP RFC 5225 
0x0103 ROHCv2 ESP RFC 5225 
0x0104 ROHCv2 IP RFC 5225 
0x0107 ROHCv2 RTP/UDP-Lite RFC 5225 
0x0108 ROHCv2 UDP-Lite RFC 5225 


New profiles will need new identifiers to be assigned by the IANA, 
but this document does not require any additional IANA action. 


9. Security Considerations 


Because encryption eliminates the redundancy that header compression 
schemes try to exploit, there is some inducement to forego encryption 
of headers in order to enable operation over low-bandwidth links. 


A malfunctioning or malicious header compressor could cause the 
header decompressor to reconstitute packets that do not match the 
original packets but still have valid headers and possibly also valid 
transport checksums. Such corruption may be detected with end-to-end 
authentication and integrity mechanisms, which will not be affected 
by the compression. Moreover, the ROHC header compression scheme 
uses an internal checksum for verification of reconstructed headers, 
which reduces the probability of producing decompressed headers not 
matching the original ones without this being noticed. 


Denial-of-service attacks are possible if an intruder can introduce, 
for example, bogus IR, IR-DYN, or feedback packets onto the link and 
thereby cause compression efficiency to be reduced. However, an 
intruder having the ability to inject arbitrary packets at the link 
layer in this manner raises additional security issues that dwarf 
those related to the use of header compression. 
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Appendix A. CRC Algorithm 


#!/usr/bin/perl -w 
use strict; 


hexadecimal form and then press Control+D. 


utility 


de de de db db db db db db db db dE 


sub dump bytes($) { 
my $x = shift; 
my $i; 
for ($i = 0; $i < length($x); ) { 


March 2010 


ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02 


This little demo shows the four types of CRC in use in RFC 3095, 
the specification for robust header compression. 


Type your data in 


printf("$02x ", ord(substr($x, $i, 1))); 
printf("\n") if (++$i % 16 == 0); 
} 
printf("\n") if ($i % 16 != 0); 
} 
# a a PCT CIT m 
# 
# The CRC calculation algorithm. 
# 
sub do crc($$$) { 
my $nbits - shift; 
my Spoly = shift; 
my $string = shift; 
my $crc = ($nbits == 32 ? Oxffffffff (1 «« $nbits) - 1); 
for (my $i = 0; $i < length ($string); ++$i) { 
my Sbyte = ord(substr ($string, $i, 1)); 
for( my $b = 0; Sb < 8; $b++ ) { 
if (($cre & 1) ^ (Sbyte & 1)) ( 
$crc >>= 1; 
$crc ^- Spoly; 
) else ( 
$crc >>= 1; 
} 
Sbyte >>= 1; 
} 
} 
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printf "2d bits, ", Snbits; 
printf "CRC: %02x\n", Scrc; 


# -———————— EEEN EE E EE ee ee ae 

# 

# Test harness 

# 

$/ = undef; 

$_ = <>; # read until EOF 

my $string = ""; # extract all that looks hex: 
s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg; 


dump bytes ($string); 


# 32-bit segmentation CRC 
# Note that the text implies this is complemented like for PPP 
# (this differs from 8, 7, and 3-bit CRC) 


# 

# C(x) = x^O + x^l + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + 
# MATT St AAD F XALO E x^22 HE x^238 ct x^26. t x^32 
# 

do crc(32, 0xedb88320, Sstring); 

# sa ee ——————— Hu 

# 

# 8-bit IR/IR-DYN CRC 

# 

# C(x) = x*0 + x^l + x^2 + x^8 

# 

do crc(8, 0xe0, $string); 

# T m ei a SS om roro. 

# 

# 7-bit FO/SO CRC 

# 

# C(x) = x*0 + x^l + x^2 + x^3 + x^6 + x^] 
# 

do crc(7, 0x79, $string); 

# A es pc EE E ee nm 

# 

# 3-bit FO/SO CRC 

# 

# C(x) = x40 + x41 + x^3 

# 


do crc(3, 0x6, $string); 
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